Model-Driven Development (MDD) is an approach to software development that uses a model, historically described in UML (Unified Modeling Language), to visualize a software-based application. Participants in software development, for example, architects, business analysts, programmers, and testers, prize MDD for its ability to provide a high-level visual view of the application through various representations of the model. In addition to providing this high-level view, MDD governs the correct implementation of the application and greatly reduces the time until the application becomes ready to run. MDD tooling (called “transformations”) reads in the model for the application and writes out an implementation (e.g. Eclipse-based projects, folders, files).
Historically, MDD tooling has provided a low return on investment (ROI), as the skills needed to build the typical MDD solution, for example, strong programming skills, subject matter expertise, and skills related to DB/UML API (database modeling application program interface), and the time required to build manually the MDD tooling were often more costly than the value of the MDD tooling itself. Consequently, industry has produced methodologies to reduce the time to develop MDD solutions, thereby improving the ROI for MDD tooling. Examples of such methodologies are described in U.S. Pat. No. 7,376,933, titled “System and Method for Creating Application Content using an Open Model. Driven. Architecture, in U.S. Pat. No. 7,000,218, titled “System and Method of Identifying and Tracking Software Pattern Metrics, and in U.S. application Ser. No. 10/904,105, titled “System and Method for Building an Open Model Driven Architecture Pattern Based on Exemplars”, the entirety of which patents and patent application are incorporation by reference herein.
Hereafter, MDD solutions are also referred to as “patterns”. As defined herein, a pattern is a solution to a recurring problem in a given context. In general, a pattern is an executable software tool that, when run (typically as a background executable component), generates a set of projects, folders, and files according to a given set of architectures, designs, best practices, and naming conventions. These generated projects, folders, and files are examples of artifacts, that is, tangible byproducts generated by the execution of the pattern. If any of the architectures, designs, best practices, or naming conventions in the set were to be changed, a different pattern is needed to generate the artifacts for that different set. Patterns can also be used to generate other patterns, thereby reducing the time-to-value and, conversely, increasing the ROI for those generated patterns.
Patterns, however, assume the existence of an input model describing the artifacts to be generated, and often the tools required to populate pattern-specific models do not exist and have to be built manually (i.e., user input supplied through an editor). Some of these populating editors can be quite complex and difficult to build. As a result, the overall ROI of such patterns is reduced.